09/823,084 Date: 7/5/07 



SYSTEM:OS - DIALOG OneSearch 
File 15:ABI/Inform(R) 1971-2007/Jul 05 

(c) 2007 ProQuest Info&Learning 
File 9:Business & Industry(R) Jul/1994-2007/Jun 29 

(c)2007 The Gale Group 
File 810:Business Wire 1986-1999/Feb 28 

(c) 1999 Business Wire 
File 275:Gale Group Computer DB(TM) 1983-2007/Jul 02 

(c) 2007 The Gale Group 
File 476:Financial Times Fulltext 1982-2007/Jul 05 

(c) 2007 Financial Times Ltd 
File 610:Business Wire 1999-2007/Jul 05 

(c) 2007 Business Wire. 
*File 610: File 610 now contains data from 3/99 forward. 
Archive data (1986-2/99) is available in File 810. 
File 624:McGraw-Hill Publications 1985-2007/Jul 05 

(c) 2007 McGraw-Hill Co. Inc 
*File 624: Homeland Security & Defense and 9 Piatt energy journals added 
Please see HELP NEWS624 for more 
File 636:Gale Group Newsletter DB(TM) 1987-2007/Jul 02 

(c) 2007 The Gale Group 
File 621 :Gale Group New Prod.Annou.(R) 1985-2007/Jul 02 

(c) 2007 The Gale Group 
File 613:PR Newswire 1999-2007/Jul 05 . 

(c) 2007 PR Newswire Association Inc 
*File 613: File 613 now contains data from 5/99 forward. 
Archive data (1987-4/99) is available in File 813. 
File 81 3:PR Newswire 1987-1999/Apr 30 

(c) 1999 PR Newswire Association Inc 
File 16:Gale Group PROMT(R) 1990-2007/Jul 02 

(c) 2007 The Gale Group 
File 160:Gale Group PROMT(R) 1972-1989 

(c) 1999 The Gale Group 
File 634:San Jose Mercury Jun 1985-2007/Jun 29 

(c) 2007 San Jose Mercury News 
File 148:Gale Group Trade & Industry DB 1976-2007/Jul 02 

(c)2007 The Gale Group 
*File 148: The CURRENT feature is not working in File 148. 
See HELP NEWS 148. 

File 20:Dialog Global Reporter 1997-2007/Jul 05 

(c) 2007 Dialog 
File 35 dissertation Abs Online 1861-2007/Jun 
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(c) 2007 ProQuest Info&Learning 
File 583:Gale Group Globalbase(TM) 1986-2002/Dec 13 

(c) 2002 The Gale Group 
*File 583: This file is no longer updating as of 12-13-2002. 
File 65:Inside Conferences 1993-2007/Jul 05 

(c) 2007 BLDSC all its. reserv. 
File 2:INSPEC 1898-2007/Jun W4 

(c) 2007 Institution of Electrical Engineers 
File 474:New York Times Abs 1969-2007/Jul 04 

(c) 2007 The New York Times 
File 475: Wall Street Journal Abs 1973-2007/Jul 05 

(c) 2007 The New York Times 
File 99:Wilson Appl. Sci & Tech Abs 1983-2007/Jun 

(c) 2007 The HW Wilson Co. 
File 348 EUROPEAN PATENTS 1978-2007/ 200727 

(c) 2007 European Patent Office 
*File 348: For important information about IPCR/8 and forthcoming 
changes to the IC= index, see HELP NEWSIPCR. 
File 349:PCT FULLTEXT 1979-2007/UB=20070628UT=20070621 

(c) 2007 WIPO/Thomson 
*File 349: For important information about IPCR/8 and forthcoming 
changes to the IC= index, see HELP NEWSIPCR. 
File 347:JAPIO Dec 1976-2007/Dec(Updated 070702) 
(c) 2007 JPO & JAPIO 

Set Items Description 



? s (download??? ?) (5n) (proxy) (s) (object (5n) broker) 
1635361 DOWNLOAD???? 
400151 PROXY 
2003214 OBJECT 
1347854 BROKER 

5 1 4 (DOWNLOAD??? ?) (5N) (PROXY) (S) (OBJECT (5N) BROKER) 
? s si and py<2001 

Processing 

Processed 10 of 26 files ... 
Processing 

Processed 20 of 26 files ... 
Processing 

Completed processing all files 
4 SI 

73572271 PY<2001 

52 0 SI AND PY<2001 
?ds 

Set Items Description 
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5 1 4 (DOWNLOAD??? ?) (5N) (PROXY) (S) (OBJECT (5N) BROKER) 

52 0 S1ANDPY<2001 
? show files;ds 

File 15:ABI/Inform(R) 1971-2007/Jul 05 

(c) 2007 ProQuest Info&Learning 
File EBusiness & Industry(R) Jul/1 994-2007/Jun 29 

(c)2007 The Gale Group 
File 810:Business Wire 1986-1999/Feb 28 

(c) 1999 Business Wire 
File 275:Gale Group Computer DB(TM) 1983-2007/Jul 02 

(c) 2007 The Gale Group 
File 476:Financial Times Fulltext 1982-2007/Jul 05 

(c) 2007 Financial Times Ltd 
File 610:Business Wire 1999-2007/Jul 05 

(c) 2007 Business Wire. 
File 624:McGraw-Hill Publications 1 985-2007/Jul 05 

(c) 2007 McGraw-Hill Co. Inc 
File 636:Gale Group Newsletter DB(TM) 1987-2007/Jul 02 

(c) 2007 The Gale Group 
File 621:Gale Group New Prod.Annou.(R) 1 985-2007/Jul 02 

(c) 2007 The Gale Group 
File 613:PR Newswire 1999-2007/Jul 05 

(c) 2007 PR Newswire Association Inc 
File 813:PR Newswire 1987-1999/Apr 30 

(c) 1999 PR Newswire Association Inc 
File 16:Gale Group PROMT(R) 1990-2007/Jul 02 

(c) 2007 The Gale Group 
File 160:Gale Group PROMT(R) 1972-1989 

(c) 1999 The Gale Group 
File 634:San Jose Mercury Jun 1985-2007/Jun 29 

(c) 2007 San Jose Mercury News 
File 148: Gale Group Trade & Industry DB 1976-2007/Jul 02 

(c)2007 The Gale Group 
File 20:Dialog Global Reporter 1997-2007/Jul 05 

(c) 2007 Dialog 
File 35:Dissertation Abs Online 1861-2007/Jun 

(c) 2007 ProQuest Info&Learning 
File 583:Gale Group Globalbase(TM) 1986-2002/Dec 13 

(c) 2002 The Gale Group 
File 65: Inside Conferences 1993-2007/Jul 05 

(c) 2007 BLDSC all rts. reserv. 
File 2:INSPEC 1 898-2007/Jun W4 

(c) 2007 Institution of Electrical Engineers 
File 474:New York Times Abs 1969-2007/Jul 04 

(c) 2007 The New York Times 
File 475:Wall Street Journal Abs 1973-2007/Jul 05 
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(c) 2007 The New York Times 
File 99: Wilson Appl. Sci & Tech Abs 1983-2007/Jun 

(c) 2007 The HW Wilson Co. 
File 348:EUROPEAN PATENTS 1978-2007/ 200727 

(c) 2007 European Patent Office 
File 349:PCT FULLTEXT 1979-2007/UB=20070628UT=20070621 

(c) 2007 WIPO/Thomson 
File 347:JAPIO Dec 1976-2007/Dec(Updated 070702) 

(c) 2007 JPO & JAPIO 

Set Items Description 

5 1 4 (DOWNLOAD??? ?) (5N) (PROXY) (S) (OBJECT (5N) BROKER) 

52 0 S1ANDPY<2001 
?tsl/3,k/l-4 

1/3,K/1 (Item 1 from file: 349) 
DIALOG(R)File 349:PCT FULLTEXT 
(c) 2007 WIPO/Thomson. All rts. reserv. 

00784185 **Image available** 

A SYSTEM AND METHOD FOR STREAM-BASED COMMUNICATION IN A 
COMMUNICATION 

SERVICES PATTERNS ENVIRONMENT 
SYSTEME, PROCEDE ET ARTICLE DE PRODUCTION FOURNISSANT UN 
SYSTEME DE 

COMMUNICATION EN CONTINU DANS UN ENV IRONNEMENT DE 
CONFIGURATIONS DE 

SERVICES DE COMMUNICATION 
Patent Applicant/Assignee: 
ACCENTURE LLP, 1661 Page Mill Road, Palo Alto, CA 94304, US, US 

(Residence), US (Nationality) 
Inventor(s): 

BOWMAN-AMU AH Michel K, 6426 Peak Vista Circle, Colorado Springs, CO 80918 
,US, 

Legal Representative: 

HICKMAN Paul L (agent), Hickman Coleman & Hughes, LLP, P.O. Box 52037, 
Palo Alto, CA 94303-0746, US, 
Patent and Priority Information (Country, Number, Date): 

Patent: WO 200117195 A2-A3 20010308 (WO 0117195) 

Application: WO 2000US24 125 20000831 (PCT/WO US0024125) 

Priority Application: US 99386717 19990831 
Designated States: 

(Protection type is "patent" unless otherwise stated - for applications 
prior to 2004) 

AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK 
DM DZ EE 
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ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS 
LT 

LU LV MA MDMGMKMN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK 
SL TJ TM 

TR TT TZ UA UG UZ VN YU ZA ZW 

(EP) AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE 

(OA) BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG 

(AP) GH GM KE LS MW MZ SD SL SZ TZ UG ZW 

(EA) AM AZ BY KG KZ MD RU TJ TM 
Publication Language: English 
Filing Language: English 
Fulltext Word Count: 150532 

Fulltext Availability: 
Detailed Description 

Detailed Description 

... datasets. Ideally, the architecture would permit definition of 
retention periods and disposition requirements. 

24. Report Download: The report architecture should allow 
distribution of the information contained in a report dataset to... 

1/3.K/2 (Item 2 from file: 349) 
DIALOG(R)File 349:PCT FULLTEXT 
(c) 2007 WIPO/Thomson. All rts. reserv. 

00784136 

A SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR BUSINESS 
LOGIC SERVICES 

PATTERNS IN A NETCENTRIC ENVIRONMENT 
SYSTEME, PROCEDE ET ARTICLE DE FABRICATION POUR STRUCTURES DE 
SERVICES DE 

LOGIQUE DE COMMERCE DANS UN ENVIRONNEMENT S'ARTICULANT 
AUTOUR DE 

LTNTERNET 
Patent Applicant/ Assignee: 
ACCENTURE LLP, 1661 Page Mill Road, Palo Alto, CA 94304, US, US 

(Residence), US (Nationality) 
Inventor(s): 

BOWMAN-AMU AH Michel K, 6426 Peak Vista Circle, Colorado Springs, CO 80918 
,US, 

Legal Representative: 
HICKMAN Paul L (agent), Oppenheimer Wolff & Donnelly, LLP, 38th Floor, 
2029 Century Park East, Los Angeles, CA 90067-3024, US, 
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Patent and Priority Information (Country, Number, Date): 
Patent: WO 2001 16728 A2-A3 20010308 (WO 01 16728) 

Application: WO 2000US24197 2000083 1 (PCT/WO US0024197) 
Priority Application: US 99387658 19990831 

Designated States: 

(Protection type is "patent" unless otherwise stated - for applications 
prior to 2004) 

AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK 
DM DZ EE 

ES FI GB GD GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT 
LU 

LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL 
TJ TM TR 
TT TZ UA UG UZ VN YU ZA ZW 

(EP) AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE 

(OA) BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG 

(AP) GH GM KE LS MW MZ SD SL SZ TZ UG ZW 

(EA) AM AZ BY KG KZ MD RU TJ TM 
Publication Language: English 
Filing Language: English 
Fulltext Word Count: 150863 

Fulltext Availability: 
Detailed Description 

Detailed Description 

... datasets. Ideally, the architecture would permit definition of 
retention periods and disposition requirements. 

24. Report Download: The report architecture should allow 
distribution of the infortriation contained in a report dataset to... 

1/3.K/3 (Item 3 from file: 349) 
DIALOG(R)File 349:PCT FULLTEXT 
(c) 2007 WIPO/Thomson. All rts. reserv. 

00784134 

A SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR A CONSTANT 
CLASS COMPONENT 

IN A BUSINESS LOGIC SERVICES PATTERNS ENVIRONMENT 
SYSTEME, PROCEDE ET ARTICLE MANUFACTURE UN COMPOSANT DE 
CLASSE DE CONSTANTE 

DANS UN ENVIRONNEMENT DE SCHEMAS DE SERVICES DE LOGIQUE 
D'AFFAIRES 
Patent Applicant/ Assignee: 
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ACCENTURE LLP, 1661 Page Mill Road, Palo Alto, CA 94304, US, US 
(Residence), US (Nationality) 
Inventor(s): 

BOWMAN-AMU AH Michel K, 6426 Peak Vista Circle, Colorado Springs, CO 80918 
,US, 

Legal Representative: 

HICKMAN Paul L (agent), Oppenheimer Wolff & Donnelly LLP, Suite 3800, 
2029 Century Park East, Los Angeles, CA 90067-3024, US, 
Patent and Priority Information (Country, Number, Date): 

Patent: WO 2001 16726 A2-A3 20010308 (WO 01 16726) 

Application: WO 2000US24 188 20000831 (PCT/WO US0024188) 

Priority Application: US 99387213 19990831 
Designated States: 

(Protection type is "patent" unless otherwise stated - for applications 
prior to 2004) 

AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE 
GHGM 

HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MDMGMKMN 
MW MX 

NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW 
(EP) AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE 
(OA) BF B J CF CG CI CM GA GN GW ML MR NE SN TD TG 
(AP) GH GM KE LS MW MZ SD SL SZ TZ UG ZW 
(EA) AM AZ BY KG KZ MD RU TJ TM 

Publication Language: English 

Filing Language: English 

Fulltext Word Count: 150446 

Fulltext Availability: 
Detailed Description 

Detailed Description 

... datasets. Ideally, the architecture would permit definition of 
retention periods and disposition requirements. 

24. Report Download: The report architecture should allow 
distribution of the information contained in a report dataset to... 

l/3,K/4 (Item 4 from file: 349) 
DIALOG(R)File 349:PCT FULLTEXT 
(c) 2007 WIPO/Thomson. All rts. reserv. 

00784131 

A SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR A MULTI- 
OBJECT FETCH 
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COMPONENT IN AN INFORMATION SERVICES PATTERNS ENVIRONMENT 
SYSTEME, PROCEDE ET ARTICLE MANUFACTURE POUR COMPOSANT DE 
RECUPERATION 

MULTI-OBJET DANS UN ENVIRONNEMENT CARACTERISE PAR DES 
SERVICES 

D'INFORMATIONS 
Patent Applicant/ Assignee: 
ACCENTURE LLP, 1661 Page Mill Road, Palo Alto, CA 94304, US, US 

(Residence), US (Nationality) 
Inventor(s): 

BOWMAN- AMUAH Michel K, 6426 Peak Vista Circle, Colorado Springs, CO 80918 
,US, 

Legal Representative: 

HICKMAN Paul L (agent), Oppenheimer Wolff & Donnelly LLP, Suite 3800, 
2029 Century Park East, Los Angeles, CA 90067, US, 
Patent and Priority Information (Country, Number, Date): 

Patent: WO 2001 16723 A2-A3 20010308 (WO 01 16723) 

Application: WO 2000US24083 2000083 1 (PCT/WO US0024083) 

Priority Application: US 99386238 19990831 
Designated States: 

(Protection type is "patent" unless otherwise stated - for applications 
prior to 2004) 

AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI 
GB GE 

GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD 
MGMK 

MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG 
UZ VN 
YUZW 

(EP) AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE 

(OA) BF B J CF CG CI CM GA GN GW ML MR NE SN TD TG 

(AP) GH GM KE LS MW MZ SD SL SZ TZ UG ZW 

(EA) AM AZ BY KG KZ MD RU TJ TM 
Publication Language: English 
Filing Language: English 
Fulltext Word Count: 150940 

Fulltext Availability: 
Detailed Description 

Detailed Description 

... datasets. Ideally, the architecture would permit definition of 
retention periods and disposition requirements. 

24. Report Download: The report architecture should allow 
distribution of the information contained in a report dataset to... 
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? s (download??? ?)(5n)(proxy) (s) (object (5n) broker) 
1635361 DOWNLOAD???? 
400151 PROXY 
2003214 OBJECT 
1347854 BROKER 

53 4 (DOWNLOAD??? ?)(5N)(PROXY) (S) (OBJECT (5N) BROKER) 
? s (download??? ?)(5n)(proxy) 

1635361 DOWNLOAD???? 
400151 PROXY 

54 941 (DOWNLOAD??? ?)(5N)(PROXY) 
? s s4 and boker and corba 

941 S4 
1023 BOKER 
47326 CORBA 

55 0 S4 AND BOKER AND CORBA 
? s s4 and broker and corba 

941 S4 
1347854 BROKER 
47326 CORBA 

56 44 S4 AND BROKER AND CORBA 
?rd44 

»>Set 44 has not yet been created. 
?rds4 

»>Duplicate detection is not supported for File 348. 

»>Duplicate detection is not supported for File 349. 

»>Duplicate detection is not supported for File 347. 

»>Records from unsupported files will be retained in the RD set. 

< User Break > 

u! 

»>Duplicate detection halted. 
?rds6 

»>Duplicate detection is not supported for File 348. 
»>Duplicate detection is not supported for File 349. 
»>Duplicate detection is not supported for File 347. 

»>Records from unsupported files will be retained in the RD set. 

57 44 RD S6 (unique items) 
?ss7andpy<2001 
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Processing 

Processed 10 of 26 files ... 
Processing 

Processed 20 of 26 files ... 
Completed processing all files 
44 S7 
73572271 PY<2001 
S8 1 S7ANDPY<2001 
? t s8/9,k/l 

8/9,K/l (Item 1 from file: 15) 
DIALOG(R)File 15:ABI/Inform(R) 
(c) 2007 ProQuest Info&Learning. All its. reserv. 

01850272 05-01264 

The Jini Architecture for network-centric computing 
Waldo, Jim 

Communications of the ACM v42n7 PP: 76-82 Jul 1999 ISSN: 0001-0782 
JRNL CODE: ACM 

DOC TYPE: Journal article LANGUAGE: English LENGTH: 7 Pages 
SPECIAL FEATURE: Charts References 
WORD COUNT: 3864 

DESCRIPTORS: Java; Computer networks; Connectivity; Computer architecture; 
Studies 

CLASSIFICATION CODES: 5240 (CN=Software & systems); 9130 
(CN=Experimental/Theoretical) 

ABSTRACT: The Jini architecture exemplifies a new approach to computing 
systems - making the network the central connecting tissue. By replacing 
the notion of peripherals and applications with that of network-available 
services and clients that use those services, the Jini system breaks down 
the conventional view of what a computer is, while including new classes of 
devices in a unified architecture. Jini technology is not a distributed 
operating system (in the traditional sense) or an application. It is, in a 
classic sense, a system defining a small, simple set of conventions that 
allows services and clients to form a flexible distributed system that can 
change easily over time. The Jini system is Java-centric - because it 
builds on the existing Java environment and because it requires features 
that are widely available only within the Java platform. 

TEXT: Headnote: 

A federation of spontaneously networked electronic components of all types 
can communicate, interact, and share their services and functions, as 
explained by Jini ? s lead architect. 
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THE JINI ARCHITECTURE EXEMPLIFIES A NEW APPROACH TO COMPUTING 

systems-making the network the central connecting tissue. By replacing the 

notion of peripherals and applications with that of network-available 

services nd clients that use those services, the Jini system breaks down 

the conventonal view of what a computer is, while including new classes of 

devices in a unified architecture. 

Jini technology assumes a changing network, in terms of both the components 
that make up the network and the way these components interact. Networks 
are generally long-lived entities that, as they grow to include ever-larger 
populations of users and machines, become increasingly difficult to upgrade 
as a single entity. That's why the Jini architecture is designed around 
support for incrementally upgrading network components (hardware and 
software) [9]. So, for example, installing a network printer in a Jini 
environment involves simply plugging it into the network and turning on the 
power; removing it from the network involves no more than unplugging it. 

Because it is designed for the network, Jini challenges the presuppositions 
that have shaped conventional thinking about computers and how software is 
written for them. The result is a system that offers considerable new power 
but is simpler to use and adapt than current systems. 

Jini allows anything with a processor, some memory, and a network 
connection to offer services to other entities on the network or to use the 
services that are so offered. This class of devices includes all the things 
we traditionally think of as computers but also most of the things we think 
of as peripherals, such as printers, storage devices, and specialized 
hardware. In the near future, the definition will also encompass a host of 
other devices, such as cell phones, personal digital assistants, and 
microprocessor— controlled devices, such as televisions, stereo 
components, and even modern thermostats. 

Making the network central requires a design that allows updates and 
changes to individual components without the wholesale shutdown of the 
network. Unlike a single machine, a large network cannot be shut down 
without great difficulty; updating the entire network is more difficult 
still. So the Jini system allows upgrades and updates to be installed and 
used by the components being networked without requiring that the network 
be shut down or all individual components be updated. 

An additional result of building around the network is that the data and 
code running on any device in the network cannot be assumed by users or 
developers to have been built especially for that device. Indeed, given the 
longevity of networks and the rapid rate of change in small devices, the 
code and the information used on a particular processor is often 
constructed or gathered long before the processor is designed or built. 
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The combination of rapid change and long-running networks imposed another 
goal on Jini's designers. Users of a Jinibased network should be able to 
add or remove member components without having to update other member 
components in the network community. Further, the way these components 
communicate with one another had to be able to change over time. 

A final goal for Jini's designers was imposed by the size of today's 
networks and how rapidly they are growing. If we have all the embedded 
systems that could possibly be given access to a network as part of our 
system, Jini technology has to be able to scale to levels previously 
unthought of (The specifications for the Jini system, along with the source 
code for the reference implementation, are at www.sun.com/jini.) 

A Simple Set of Conventions 

Jini technology is not a distributed operating system (in the traditional 
sense) or an application. It is, in a classic sense, a system defining a 
small, simple set of conventions that allows services and clients to form a 
flexible distributed system that can change easily over time. 

We separated the system's various components into the infrastructure, the 
programming model, and the clients and services themselves. While each of 
these components is logically independent, together they can use one 
another to make an overall system that is more flexible and reliable than 
the sum of its parts. 

Each component of the Jini system can be viewed as a logical extension of 
the Java language system to the fully distributed case [1,3] (see Figure 
1). The Jini infrastructure is built on the Java Remote Method Invocation 
system, which has been part of the Java platform since the release of Java 
1.1 in January 1997 [12]. On top of this base, Jini adds to the 
infrastructure two components: the discovery protocol, which allows an 
entity wishing to join a Jini network to find a lookup service, and the 
lookup service, which acts as a place where services advertise themselves 
and clients go to find a service. 

The Jini programming model consists of three sets of interfaces meant to 
extend the usual single virtual machine programming model at the core Java 
programming libraries to allow the connection of distributed objects in 
robust ways. One set of interfaces defines a distributed event model that 
is an extension of the standard Java event model in Java Beans [7]. A 
second set of interfaces enables a two-phase-commit protocol-a simplified 
distributed version of the transaction model in the Java transaction 
service [8]. Finally, there is a set of interfaces and classes that define 
the notion of leasing, developed specifically for problems in resource 
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allocation and reclamation in distributed systems. 

The Jini system's services and the clients that use them are open-ended; 
the services offered depend on the Jini federation-the informal group of 
clients and services that use the Jini-defined interaction patterns-in 
question and the time one happens to be looking at the federation. The 
other parts of the system aid in offering and finding these services. The 
vast range of services that can live in the system includes hardware 
implementations of Jini interfaces, software services that act as 
distributed components, and hardware/software combinations. 

Jini and Java 

The Jini system is Java-centric-because it builds on the existing Java 
environment and because it requires features that are widely available only 
within the Java platform. The Jini enabler is the ability of a service to 
move code into a client that wants to make use of that service. Such 
mobility is not unique to the Java environment; indeed, other systems, such 
as Inferno, a network operating system from Bell Laboratories [2], 
Telescript, an objectoriented programming language from General Magic, Inc. 
[ 11], and Tel, a scripting language from Scriptics Corp. [6], have all 
been used for mobile code. However, the Java environment combines mobile 
code with other important properties that make exploitation of that 
mobility easy and safe. 

Java's most basic property is that it turns an otherwise heterogeneous 
network of computing entities into a homogeneous collection of Java virtual 
machines. By ensuring a basic and consistent environment in which the Jini 
system can exist, services written in the Java language can provide 
implementations that run in the environment of the clients that want to use 
these services. 

While the Java environment provides homogeneity with respect to the virtual 
machine and its basic class libraries, the resources on a particular 
machine can vary widely. But in a Jini environment, such resource 
variations are far less important than they would be in a more traditional 
mobile-code environment, since programs written for the ini environment 
look for all such resources on the network, not only those on an individual 
machine. 

A second property enabled by the Java environment is mobile object code. 
Most software engineers are accustomed to the notion of code portability, 
but it has always been source code that is portable. Java allows the byte 
codes the Java source is compiled into to be moved from machine to machine. 
This portability also yielded Java's "write— once-run-everywhere" slogan. 
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(Table Omitted) 



Captioned as: Figure I 
(Table Omitted) 

Captioned as: Figure 2 

The write-once-run-everywhere property of Java byte codes, when coupled 
with the dynamic nature of Java, allows object code to be moved and 
dynamically loaded into a process even while the process is running. The 
Jini system uses the dynamic moving and loading of code to allow new 
functions to be introduced into a running program. This dynamic nature of 
the Java environment is a third enabler of the Jini system. 

Being able to move code to a new system and dynamically load that code into 
a running process allows great flexibility, but it also introduces serious 
risk to the program accepting the code. Allowing code to be imported into a 
running process from possibly unknown sources requires a level of trust few 
users are willing to grant. However, Java ! s inherent security can be relied 
on to allow such trust. Another property of the Java environment enabling 
Jini is its inherent safety-in the sense of referential integrity, array- 
bounds checking, and type safety The Java security model also allows 
fine-grain control of the operations that can be performed by any code. 

While the Jini system design assumes the Java environment will run on all 
components, Jini requires only that there be a Java virtual machine 
somewhere on the network. Components unable to run the Java environment can 
delegate functions requiring a Java virtual machine to this other machine 
[10]. 

Spontaneous Networking 

The Jini infrastructure, combined with the Java environment's ability to 
move code safely, allows the system to represent a spontaneous form of 
networking. Services and clients can join or leave a network federation 
anytime. More important, new and enhanced services can be introduced to 
extend the functionality of the networked federation. 

The notion of a proxy is central to the Jini system-as well as to many 
other distributed systems. 

A proxy is a local object that stands in for the remote object. While 
presenting the same programmatic interface to the local code, the proxy 
deals with any network-related functions, transmitting any parameters to 
the remote service and receiving any return values from that service. 
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A service (hardware or software) that wants to join a Jini federation sends 
out a packet, multicast over the LAN to a well-known port, asking for any 
lookup service to respond. The packet might specify that only lookup 
services within a particular (named) group respond, but in the simplest 
case, any and all lookup services on the local network would respond. The 
packet also contains the information necessary for any lookup service to 
respond to the requester. 

Upon receipt of such a request, a lookup service responds by sending the 
requester a local proxy to the lookup service. This proxy, when loaded into 
the Java virtual machine running on the requester, contains enough 
information that, if the code needed for the proxy is not present at the 
site of the requester, it can be downloaded over the network. 
Therefore, the proxy returned to the requester is always matched to 
the lookup service that sent it (see Figure 2). 

Upon receipt of a proxy for a lookup service, a service can register to 
offer itself for use to other members of the Jini federation by placing a 
proxy object of its own in the lookup service. If the service has received 
a response to more than one lookup service, it can register itself in any 
or all of these services. 

Clients looking for a service find the lookup service in the same way-by 
multicasting a discovery request. Upon receipt of a proxy from any 
available lookup service, a client can request a service. Such a request 
takes the form of asking for an object implementing a particular Java 
language type. So, for example, a client could ask for something-either 
hardware or software-that implements a Java printing interface, rather 
than asking for something called a printer (see Figure 3). 

This distinction is important, as it allows the lookup service to return a 
subtype of the requested type. If a client requests something of type 
printer, the lookup service is permitted to return a proxy for a subtype of 
the printer type, possibly a color printer. As in any strongly typed 
object-oriented system, this subtype includes all the characteristics of 
the requested super type, but also has additional behaviors. The client can 
then use these additional behaviors, which can be found through the Java 
language's reflection and type-discovery operations. If the client needs 
the code that implements the new behaviors, this code is downloaded 
when the proxy is recreated in the client's Java virtual machine. 

Since the proxy used by the client to talk to a service is placed in the 
lookup service by the entity to which it communicates, the proxy can know 
details about the service to which it talks. All the client needs to know 
about the proxy is the Java interface it supports. This interface-based 
communication means that the proxy and the service can talk by way of 
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whatever protocol they need. Further, the way the proxy talks to the 
service can change over time without the clients needing to be altered or 
even to be aware of the change (see Figure 4). 

The ability of the service to move code into the client means that all the 
client has to worry about is the interface to the service. The actual 
implementation of the interface is a private matter between the service and 
the proxy supplied by the service. Since the client finds the service 
through its Java language type, the client knows the programmatic interface 
needed to talk to the service. This interface-based approach moves 
object-oriented programming techniques out of the address space and onto 
the network; all the client need worry about is what it needs done 
(expressed in the interface), not how it is done. 

The ability to move code from the service to its client is the core 
difference between the Jini environment and other distributed systems, such 
as the Common Object Request Broker Architecture (CORBA) [4] 
and the Distributed Common Object Model (DCOM) [5]. In such systems, the 
code used to communicate with a service is associated with the client and 
knows how to transfer information to the service using a static protocol 
defined in terms of an interface definition language, which defines the 
information exchanged. This built-in knowledge means that any change in the 
communications protocol requires a coordinated change in both the client 
and the service. 

(Illustration Omitted) 

Captioned as: Figure 3 

(Illustration Omitted) 

Captioned as: Figure 4 

Using mobile code, the Jini environment downloads the code used to 
communicate with the service into the client at the time the client wants 
to use the service. Changes in the protocol are private to the service and 
to the code sent to the client by that service. This privacy allows changes 
to be propagated as needed without the client's being aware of the changes. 

The discovery protocol and the lookup service allow clients and service 
providers to join a Jini federation spontaneously. However, a genuinely 
spontaneous federation also requires that clients and services be able to 
leave the federation easily in a way that is not disruptive to its other 
members. The ability to leave is accomplished through the Jini programming 
model, which includes the notion of "leasing" resources. Services and 
clients can leave a Jini federation easily by way of the Jini leasing 



16 



model. 

Jini f s leasing model introduces time into the allocation of resources. A 

Jini member component offering a resource does so through a lease, in a way 

that does not allow the resource to be used until it is explicitly 

released. 

The lease represents a period of time during which the resource is 
available. The client wanting the resource requests a lease period, but the 
actual period of the lease is determined by the grantor of the resource. 

Even a lease that is handed out can be cancelled by the client holding the 
lease-if the client is finished with the leased resource before the lease 
expires. The lease can also be renewed-if the client requests it and the 
grantor agrees. However, when the lease expires, the lease grantor may free 
up the leased resource, and the lease holder knows the resource's 
availability is no longer guaranteed. 

To see how Jini service leasing works, consider the Jini lookup service, 
which leases service registrations. Any service registering with a lookup 
service is granted a lease on that registration. Cancelling the lease is 
equivalent to unregistering with the lookup service. The service is 
expected to renew the lease for as long as it wants to be available to 
clients looking for that kind of service. 

However, if the lease expires because it was not renewed (due to, say, a 
network failure, a service crash, or the service's being abruptly removed 
from the network), the service registration is dropped. Such lease 
expiration allows services to be removed from the Jini federation without 
warning or administrative intervention. Moreover, the federation can 
reflect the loss of that particular service in a timely fashion. This quick 
reflection of the loss of a service represents the other half of 
spontaneous networking, complementing the discovery and join functions. 

Federation and Centralized Control 

In the broadest sense, a Jini federation is defined by the set of services 
registered with a particular (set of) lookup service(s) and the clients 
using these lookup services to find these registered needed services. 

But the term "federation" conveys more than just this limited definition. 
In a federated system of government, most of the power belongs to the local 
authorities, with federal authorities having only the authority to ensure 
local entities work together. Similarly, the Jini system aims to provide 
the minimal set of rules to allow clients and services to find each other 
and interact. By supplying the lookup service and the discovery protocol, a 
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Jini federation dictates how its members join, leave, and find one another. 
And by dictating the use of the Java language's type system, the Jini 
federation dictates how services are identified. The Jini programming model 
codifies certain common styles of object interaction. Finally, by requiring 
that the proxy code for a service be downloadable, the Jini federation 
dictates how the services and their clients manage change in their 
implementations and the way they are extended. 

Using a federated model instead of the usual model of centralized control 
(as in distributed operating systems) was a conscious decision by the Jini 
designers. While centralized systems can be optimized for some cases, 
changing them over time is difficult. More important, centralized systems 
do not scale well-and as Jini federations (and federations of federations) 
begin to emerge, they have to scale to very large numbers. The federated 
approach allows such scaling in ways not available to centralized systems. 

Disk-centric Computing 

The concentration on the network, the ability to move code, and the 
federated nature of the Jini system result in an architecture that is 
fundamentally different from the one used for the past 50 years. 
Traditional computing architectures are built around three central 
components: the central processing unit, which does the computing; dynamic 
memory, where temporary results are stored; and a disk, which acts as 
stable storage. These elements have supported the computing industry since 
the earliest days of the stored-program computer in the late 1940s and 
early 1950s. 

Given the changes in the technology, it is surprising that this 
architecture has remained so stable for so long. Each of the components has 
decreased in size and increased in capacity and speed during the 50 years 
of computing history, but their relationship has remained remarkably 
constant. The transitions from mainframes to minicomputers to workstations 
to personal computers changed many things about the way we build hardware 
and design software. But in all these transitions, the base of the computer 
itself has remained the CPU, dynamic memory, and a disk for stable storage. 

We are so familiar with this kind of architecture, we tend to forget that 
there are implications to this approach. An obvious example is the nearly 
universal use of virtual memory, which allows part of the disk to be used 
to augment a computer's physical memory. The fact that virtual memory is 
part of nearly every commercial operating system is an outgrowth of the 
assumption that memory and disk are always present together. 

There are more interesting, and subtler, implications of this architectural 
assumption. For example, because we assume that the processor is tightly 
associated with a disk, we store programs on disks that are compiled 



18 



specifically for a particular kind of processor. Associating storage and 
processor leads to binary programs that are finely tuned to a particular 
kind of processor-and cannot be used on any other kind. 

Moving to a network-centric design means that these assumptions cannot be 
made. The code that is to be run on a particular processor may come from 
any part of the network and therefore cannot be specialized for any 
particular kind of processor. Indeed, given the long-lived nature of 
networks, the code run on a particular processor may have been placed on 
the network long before the processor was even designed. 

While processor-independence makes it impossible to specialize the code to 
a processor, the coupling between code and machine is far looser than has 
been the case historically. This looser coupling allows new services to be 
introduced into the network and inject their code into the processors that 
want to use the service for instant connection. This architecture makes the 
network the computer and allows connectivity to achieve a simplicity never 
before possible. 
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